Apple, the Apple logo, and Macintosh are registered trademarks of Apple Computer, Inc.
Mac and OpenDoc are trademarks of Apple Computer, Inc.
Changes since DR4
The following are changes to the OpenDoc recipes and documentation for Drag & Drop since DR4.
Class Reference:
• p. 192, §6 - Add after last sentence:
Note: The value of destPart returned by StartDrag is for future use. For now, you should not call any methods of this object, although object pointer comparisons can be done, such as to check if the drop occured in your part. The only exception to this rule is that your part needs to call the destination part's Release method.
• p. 193, §3 - Add after last sentence.
See also ODPart::Release (page xxx).
• p. 484, §2 - Add after first sentence:
In addition, if your part calls SetDroppable with a value of kODTrue on one of its display frames, you must
override this method and implement the protocol for drag hiliting and accepting dropped data.
• p. 484, §4 - Add after last sentence:
The ODFrame::SetDroppable method (page xxx).
The ODPart::Drop method (page xxx).
• p. 485, §3 - Add after last sentence:
In addition, if your part calls SetDroppable with a value of kODTrue on one of its display frames, you must
override this method and implement the protocol for drag hiliting and accepting dropped data.
• p. 485, §4 - Add after last sentence:
The ODFrame::SetDroppable method (page xxx).
The ODPart::Drop method (page xxx).
• p. 487, §1 - Add after first sentence:
In addition, if your part calls SetDroppable with a value of kODTrue on one of its display frames, you must
override this method and implement the protocol for drag hiliting and accepting dropped data.
• p. 487, §3 - Add after last sentence:
The ODFrame::SetDroppable method (page xxx).
The ODPart::Drop method (page xxx).
Programmer’s Guide:
• p. 363, §6 -Add after first sentence:
However, if you do make your part’s frames droppable, you must override the ODPart API methods DragEnter,
DragWithin, DragLeave, and Drop, and follow the protocol for drag hiliting and accepting dropped data.
• p. 365, §3 - Add after the last sentence "...should not allow them to be drop targets."
This includes all corresponding frames in other windows that have other representations of your part's data, such as if your part was opened into another window using the "View as Window" or "Open Selection" menu items.
• p. 366, § 5 - Add after first sentence:
Getting the data from the drag item iterator is a potentially expensive operation, and should be avoided as much as possible. Optimizations that will cause your part to not read these items will greatly enhance the performance of drag operations involving your part. One optimization is that if your part is a container, and you can accept any data dragged into it, you don’t need to check any of the items in the Drag Item iterator. Just do the usual drag feedback and return kODTrue. In addition, if your part's content model only supports dragging in a maximum number of items, you can check drag items up to the number you part supports, and if there are more, you can stop checking and return false. For example, a text editor may only support dropping a single file on it, so there is no reason to iterate through all of the drag items checking for a compatible kind if there is more than one item.
Also, your part should check your draft's permissions before accepting a drop that would result in a change to your persistent storage. An exception to this rule is a part that acts as a "grinder" that processes an incoming drag, and perhaps only creates another file, or changes the display, but does not create or modify any persistent data. If your draft is read-only and accepting the drag will chang persistent storage, do not accept the drag. See Chapter 7 "Drafts" on p. 286 for more information on draft permissions.
• p.372 - Add new paragraph after paragraph 6:
Note: The value of destPart returned by StartDrag is for future use. For now, you should not call any methods of this object, although object pointer comparisons can be done, such as to check if the drop occured in your part. The only exception to this rule is that your part needs to call the destination part's Release method. See the Class Reference documentation for information about ODPart::Release.
